Model based software solutions involve approaches and implementations in which every significant part of a software development lifecycle is modeled as data and persisted with capabilities that enable a user to perform various steps in the software development lifecycle. This data modeling requires a high level of specialization, and is usually carried out just before the start of coding. The modeled data is persisted and can be used by downstream processes thereby ensuring that all relevant data that is captured by upstream processes are used in the downstream processes without any significant loss of information.
The traditional approach to the data modeling involves an understanding of the system in its entirety including all the data dependencies between various entities in the system. A schema designer who models data, requires detailed information on various business processes addressed by the system and various constituents of the system. For example, the schema designer requires information in terms of entities that need to be stored in the system and their relationship with other data that are to be stored in the system. The data types and sizes of those entities also need to be stored.
This schema can then be represented diagrammatically and reviewed by functional specialists. As the number of entities increase, their interconnections with other entities also increase thereby increasing the complexity of the schema. A fully represented schematic diagram for a fairly complex system has many interconnections that explain the origin and destination of the relationship lines between entities.
The granularity of data captured in a model based environment depends on an extent that the model is used. For example, if functional requirements are captured at a very granular level, it enables a designer to implement these requirements with the exact business logic as envisioned by a requirements engineer.
During a typical modeling process, business logic that is captured at one point in a system is quite often applicable at some other point in the system. However, because of the granularity of the business logic, the set of business rules that may be needed to be reused may not be a single rule but a set of business rules which may form a subset of the business logic implemented elsewhere. Even though these business rules are not reused by the requirements engineer, the design engineer who analyzes them may benefit if he can identify the reuse of the business rules across the various actions. Unfortunately, the task of identifying this subset of the huge set of business rules that exist in the business process is time consuming and strenuous. This makes reuse identification a near impossibility for the design engineer.
Other features of the present embodiments will be apparent from the accompanying drawings and from the detailed description that follows.